\chapter{Design and Implementation}
\label{chap:desimp}
\section{System Architecture}
To avoid issues of coupling, and increase the cohesion of the system, the library was separated into multiple packages, each with their own purpose. This also helps to clarify the organisational structure of the library. Each package is a sub-package of the libraries primary package, which is called aspectjlib.

\begin{figure}[H]
	\caption{A UML Class Diagram of the Aspects package}
	\label{fig:uml}
	\centering
		\includegraphics[trim = 0 25 0 0, clip, width=0.8\textwidth]{images/AspectJLib.png}
\end{figure}

There are four packages in the library. There is the aspect package, which contains all of the abstract aspects that are defined by the library. There is the logging package, which deals with the output to the log files, and is the main engine behind the library. There is the enums package, which contains an enumerator that tells the logging classes which aspect is currently being used. And finally, there is the visual package, which produces the graphs from the log files. See Figure~\ref{fig:uml} for a UML class diagram showing how each class within each package relates to one another.

Outside of the src folder, there is a library (lib) folder, containing all of this product's required libraries. This folder contains AspectJ, log4j and JFreeChart. The reasoning for these choices of libraries shall be explained in Section~\ref{sec:osl} - \nameref{sec:osl}.

\section{Aspects Implementation}
\subsection{Abstract Aspects}
The library uses abstract aspects, which are found in the aspects package. This choice was made in order to make the configuration of the aspects easier, as an undefined pointcut called \lstinline!scope!. It can be defined for all aspects within a single configuration file, contained within their own application. The complete pointcut, used by all the aspects, is \lstinline!Around("scope() && execution * *.*(..))")!.

The \lstinline!Around! advice interrupts any code that fits the pattern defined by the pointcut(s) within, and enables code to be run before the pointcut. The code may then be resumed. Once the code is complete, the code is interrupted again, following the completion (be that through returning, or throwing an error), and more code may be run, using the return value from the object, if required. This method was chosen as, initially, the code was simply a single timer that went around the code continuation, before the structure of the code was fully defined. There was no reason to alter this decision as the library became more complex, even though the \lstinline!Before! and \lstinline!After! advice could just as easily been used.

The \lstinline!execution! pointcut tells the weaver to interrupt the code before execution of any method, in any package, taking in any object, and returning any object. This was chosen over using the \lstinline!call! pointcut as it also includes the use of the initial method, usually something like Main.main(). This meant that the time of all methods could be given relative to the start of the application.

\lstinline!scope()! is an abstract pointcut, which gets defined within the aop.xml configuration file. This configuration file is to be found within the META-INF folder of the application using this library.

\subsection{Aspects Package}

\begin{figure}[H]
	\caption{A UML Class Diagram of the Aspects package}
	\centering
		\includegraphics[trim = 0 25 0 0, clip, scale=0.36]{images/Aspects.png}
\end{figure}

The TimerAspect is the concretised version of the AbstractTimerAspect which, when defined, times how long is spent within each executed method, and stores it in the log file. This aspect was created to fulfil the eighth functional requirement.

The MethodTouchesAspect is the concretised version of the AbstractMethodTouchesAspect which, when defined, sums the number of times each method is executed, then sorts the result by the number of executions. This is then stored in the log file in descending order. This aspect was created to fulfil the ninth functional requirement.

\section{Logging Implementation}

\begin{figure}[H]
	\caption{A UML Class Diagram of the Logging package}
	\centering
		\includegraphics[trim = 0 25 0 0, clip, scale=0.36]{images/Logging.png}
\end{figure}

\subsection{MasterTracker}
This is called by all the aspects. It uses the CurrentAspect enum to find out which aspect called it, then uses this information to create a log file in the correct format. It uses the singleton design pattern to make sure it is always called by the aspect. The instance of it contains a HashMap of ThreadTrackers, with the keys being the thread IDs. It stores the enum that is passed to it. 

This class deals with the output for the Timer aspect. For the purposes of storing the times, it uses \lstinline!System.nanotime()!. This was chosen over \lstinline!System.currentTimeMillis()! due to its greater precision. Although \lstinline!System.nanotime()! cannot be used to give an accurate reading of the current time and date, it is very precise when measuring the difference between two times.

\subsection{ThreadTracker}
This keeps track of the stack of methods for its thread. Each thread will have a separate ThreadTracker. This also deals with the output of the Method Touches aspect.
\newpage
\section{Visual Implementation}

\begin{figure}[H]
	\caption{A UML Class Diagram of the Visual package}
	\centering
		\includegraphics[trim = 0 25 0 0, clip, scale=0.36]{images/Visual.png}
\end{figure}

\subsection{Grapher}
This class is run independently from the rest of the library, and it has to be directly run. It takes the log file generated by this library, and draws a graph to display this information. It takes in parameters that define what data should be displayed, and how it should be displayed.

It is not entirely implemented, and as such must be manually changed within the code in order to run correctly. It will currently only show a bar chart, and is configured for use with the MethodTouchesAspect. The bar chart will show different bars for each thread.
\newpage
\section{Configuration}
After adding this library to their application, there must be a way for them to configure it without needing to delve into the code, in order to fulfil the first functional requirement. This section shall explain how each configurable part of the library can be configured.

\subsection{Aspect Configuration}
\begin{figure}[H]
	\caption{aop.xml file snippet}
	\label{fig:aop}
	\lstinputlisting[language=XML,firstline=4,lastline=6,widthgobble=2]{code/aop.xml}
	\hspace{7 mm}...
	\lstinputlisting[language=XML,firstline=12,lastline=12,widthgobble=2]{code/aop.xml}
\end{figure}
The user may configure the aspects by placing an aop.xml file within their application's META-INF folder. Figure~\ref{fig:aop} shows a snippet from a sample aop.xml configuration file. The full example file can be viewed in Appendix~\ref{app:aop} - \nameref{app:aop}. The file is used to choose which aspect is run, and which package it is to run over. To select an aspect to run, remove any comment tags from it and add comment tags to the other aspects. The package that the code is run over must be defined in line 5. Figure~\ref{fig:aop} show the configuration for all packages within foo.bar. This does not include classes within foo.bar. If the project were a simple single package project, with classes only existing within foo.bar, line 12 would instead be shown as \lstinline!foo.bar.*!. Line 5, however, would remain unchanged.

\subsection{Logs}
\begin{figure}[H]
	\caption{log4j.properties file snippet}
	\label{fig:l4j}
	\lstinputlisting[language=props,firstline=5,lastline=8]{code/log4j.properties}
	\hspace{7 mm}...
	\lstinputlisting[language=props,firstline=12,lastline=12]{code/log4j.properties}
\end{figure}
The user may configure the log file from within their application. The best location for this, without having to change the code within the library, would be a config folder (config/log4j.properties). Figure~\ref{fig:l4j} shows a snippet from a sample log4j.properties configuration file. The full example file can be viewed in Appendix~\ref{app:l4j} - \nameref{app:l4j}. The example file assumes that the user is already using log4j, but can easily be changed if they are not, by removing all the parts relating to the other logger. By adding lines 5-8 to their own log4j configuration file, along with line 12, an aspect.csv file should be placed within the application's log directory. The location may be changed by editing line 6, if the user wishes. This fulfils the fourth functional requirement.

\subsection{Ant Build File}
\begin{figure}[H]
	\caption{build.xml file snippet}
	\label{fig:bxml}
	\lstinputlisting[language=xml,firstline=30,lastline=38,widthgobble=1]{code/build.xml}
	\hspace{7 mm}...
	\lstinputlisting[language=xml,firstline=46,lastline=46,widthgobble=1]{code/build.xml}
	\hspace{7 mm}...
	\lstinputlisting[language=xml,firstline=49,lastline=49,widthgobble=1]{code/build.xml}
\end{figure}
Figure~\ref{fig:bxml} shows a snippet of the build.xml file used by the Delta Calculator Case Study. Lines 30 through 38 show how the library is compiled, using its own build script (see the code for details). There are two targets that make use of \lstinline[language=xml]!"build-sub-projects"!: \lstinline[language=xml]!"compile.weaving"! and \lstinline[language=xml]!"run.weaving"!. \lstinline[language=xml]!"compile.weaving"! compiles the application as normal, and also compiles the aspectjlib, hence the dependency on \lstinline[language=xml]!"build-sub-projects"!. \lstinline[language=xml]!"run.weaving"! runs the application, using the \lstinline[language=xml]!"..aspectjweaver.jar"! agent, which will weave together the aspects in aspectjlib with the source code in the application (in this case, the Delta Calculator). The \lstinline[language=xml]!"compile.weaving"! is the dependency for this, meaning the aspectjlib should already have been compiled.

\section{Output}
\subsection{Logs}
\begin{figure}[H]
	\caption{aspect.csv output from TimerAspect}
	\label{fig:csv}
	\lstinputlisting[firstline=1,lastline=20]{logs/aspectTimerDelta.csv}
	\hspace{7 mm}etc.
\end{figure}
Figure~\ref{fig:csv} shows an example of the output generated by the library on the first case study (see Chapter~\ref{sec:evaldel} - \nameref{sec:evaldel}). This output file is generated using the TimerAspect. The top of the file contains the headings for it each column. In the case of the MethodTouchesAspect, the headings are FunctionId, ThreadId and Uses.

\subsection{Graphs}
\begin{figure}[H]
	\caption{A graph showing the number of uses of each method from the Delta Calculator Case Study}
	\label{fig:exg}
	\centering
		\includegraphics[width=\textwidth]{images/MethodTouchesDelta.png}
\end{figure}
As mentioned above, the Grapher was not entirely implemented. What was implemented was the capability to draw a bar chart based upon the MethodTouchesAspect. It reads in the data from the .csv file produced by the logger. The path to the aspect.csv file is passed by an argument.

\section{Open-source libraries}
\label{sec:osl}
AspectJ was used for the AspectJ annotations used by the aspects in the Aspects package, and for its load-time weaver that is given to the JVM. It was chosen for the reasons specified in Section~\ref{sub:sfaop} - \nameref{sub:sfaop}.

log4j is used to create the log files that are generated by the classes in the Logger package. It was chosen as it is the most popular logging library available, and hence the most likely on for the user to be able to get support with, and understand.

JFreeChart is used to generate and display the graphs created by the Grapher class. It was chosen because it had all of the functionality required to generate a graph that could be written to an image file, or shown as a JFrame, when reading from a .csv file.
